@MrCreosote, is your auth URL up to date? If so, it's currently returning a 404 instead of the expected 200.
https://github.com/kbase/auth2_client_java/actions/runs/15744652080/job/44378194368?pr=18#step:4:118

How bad KBase urls under serivces/ are handled have changed - they now return 404 vs 200 (whichi is good). Try https://ci.kbase.us/serivce/auth instead, that should still return a 200 with unparseable json

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.38%. Comparing base (7e43944) to head (ef65021).
Report is 12 commits behind head on develop.

@@            Coverage Diff             @@
##             develop      #18   +/-   ##
==========================================
  Coverage      92.38%   92.38%           
  Complexity       111      111           
==========================================
  Files              9        9           
  Lines            289      289           
  Branches          48       48           
==========================================
  Hits             267      267           
  Misses            20       20           
  Partials           2        2           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Ah, it failed on Java 8 but passed on Java 11.

need to make the test deterministic :)

Might be a blip since it got a 403, I restarted the test

Well that makes no sense

Looks like we might be hitting this: https://www.zenrows.com/blog/cloudflare-error-1010

Try http://httpstat.us/200

Total guess, but maybe the java 8 test and java 11 test user agent headers are different enough such that cloudflare complains about 8 only

Hold on, that won't test the truncation, crap

https://www.kbase.us/ might work

... except that'll probably get the cloudflare error. What we need is a url that won't get hit by that, has a longish non-json body, and returns 200

This seems to hit the spot: https://example.org